The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
Efficient database management systems (DBMSs) typically allow data blocks to be concurrently accessed by readers and writers. Readers have access to changes to data blocks made by committed transactions. However, readers are unable to access changes made by uncommitted transactions to data blocks; instead, readers access older versions of the data blocks. Thus, a DBMS may maintain read consistency based at least in part on determining, for a particular data block, which changes are committed and which changes remain uncommitted. However, data blocks fail to store inline data indicating whether changes to the data blocks are committed or uncommitted. As a result, determining whether changes are committed or uncommitted may be a time-consuming process that involves finding out which transaction made the changes and looking up the transaction's status in a separate table. In some contexts, this process may slow down readers substantially. For example, in a clustered database environment, multiple transactions may concurrently modify a data block. Thus, the slow down may be multiplied by the number of concurrent transactions, thereby causing a reader to become bottlenecked.
One approach for reducing the slow down is to store, in data blocks, inline data indicating whether changes to the data blocks are committed. However, this approach may involve significant overhead for some transactions. For example, significant memory overhead may be involved in remembering all of the data blocks that were modified by a large transaction. Additionally, significant computing overhead may be involved in (1) bringing all of the data blocks into main memory cache and (2) updating each of the data blocks to store data indicating that the large transaction has committed. Furthermore, synchronization overhead may be involved when multiple transactions compete for access to the data blocks.
Another approach for reducing the slow down is to maintain centralized data indicating committed transactions for all data blocks. The centralized data may be updated synchronously by transactions when the transactions commit. However, this approach may shift the slow down to transaction commit processing. For example, in a clustered database environment, the centralized data may have to be distributed and replicated across multiple database instances, thereby prolonging transaction commit times. Additional overhead may be incurred in maintaining the consistency of the centralized data across the multiple database instances.
Thus, there is a need for an approach that enables quickly determining whether changes are committed while minimizing the overhead involved in making the determination.